home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 25 / AACD 25.iso / AACD / Games / Freeciv / TODO < prev   
Encoding:
Text File  |  2001-08-17  |  6.5 KB  |  155 lines
  1. ============
  2. THINGS TO DO
  3. ============
  4.  
  5. Freeciv is quite mature, and we think its already a great game,
  6. but there are always things to add or improve.  This file lists
  7. some new features which are being worked on, or are planned, or
  8. desired.  (See also the file BUGS, for some known deficiencies.)
  9.  
  10. TODO:
  11. =====
  12.  
  13. - Sound support.
  14.  
  15. - Server-side player scripting.
  16.  
  17. - Diplomacy:
  18.   * Senate
  19.   * AI handle diplomacy
  20.  
  21. - Better graphics for city styles.
  22.  
  23. - Better internationalization (fix some problems, modify those
  24.   English sentences which can not be translated into most other
  25.   languages, better gui handling for different-length words,
  26.   mixed language client-server, more complete translations,
  27.   more languages).
  28.  
  29. - Make the rulesets for City Improvements and Wonders more flexible.
  30.  
  31. - Extend governments ruleset to allow Fundamentalism, and fix up AI
  32.   handling of variant governments.
  33.  
  34. - Ports to Win32 and Mac are being worked on.
  35.  
  36. - Make the code view-agnostic: remove assumptions about which tiles are
  37.   valid. Fx the assumption that the map wraps in the x direction. This
  38.   can be done by making the code use macros like whole_map_iterate and
  39.   square_iterate. The functions map_adjust_x() and map_adjust_y() should
  40.   be removed and code that use them made to use normalize_map_pos(),
  41.   is_real_tile() or a macro.
  42.   It would also be nice to remove the assumption that the x values go
  43.   [0..map.xsize[, as a proposed isometric numbering scheme doesn't have
  44.   that property.
  45.   When all code is converted the whole of the freeciv server can be
  46.   adjusted to use a flat map, an isometric map, a torus map or maybe
  47.   even a hex map, all by changing a very limited amount of code in
  48.   the right places.
  49.   Note that the AI in various places do not adjust tiles properly even
  50.   for the current numbering scheme.
  51.   It vould also be nice to get rid of the void_tile kludge.
  52.   Note that the conversion is backwards compatible, so it can be done in
  53.   small steps. No mega-patches please.
  54.  
  55. - Stop the server from sending text to the clients. Instead it should
  56.   send an enum and some values, which the client converted to a message
  57.   to show to the user. This will give the client more knowledge of the
  58.   content of the messages, needed for fx a client side AI. It will also
  59.   mean that the messages are automatically correctly localized.
  60.   Note that these new messages will have to sometimes contain city names.
  61.   A possibility of sending text should still exist, to avoid
  62.   compatability breakage when changing the server.
  63.  
  64. - Create a new "ocean" variable in the tile struct, similar to the
  65.   "continent" variable. It needs assisiated functions to be kept up to date
  66.   in both the server and the client. It should also have an associated
  67.   function is_oceans_connected(ocean1, ocean2, player) that returns if
  68.   a city exists that connects the two oceans for that player.
  69.  
  70. - Document/cleanup AI code. Rename variables to more saying names than these:
  71.   int a, c, d, e, i, a0, b0, f, g, fprime;
  72.   int j, k, l, m, q;
  73.   (taken from ai/advmilitary.c:process_attacker_want())
  74.   I would especially like to have the use of the amortize() function in
  75.   server/settlers.c documented.
  76.   I will apply patches even if they just rename a single variable.
  77.  
  78. - Unkluge the worst AI kludges. The ones I know of are:
  79.   - precalculated amortize() calls mostly in server/settlers.c
  80.   - on the goto map the move cost of units with F_IGTER is multiplied with 3
  81.   - the goto map of ships overlap one field onto land
  82.  
  83. - Replace the use of the value 255 in relation to the warmap with the
  84.   MAXCOST constant.
  85.  
  86. - Make the server warmap use short instead of char, and raise MAXCOST from
  87.   255 to the maxvalue of a signed short. (also see prev. item)
  88.  
  89. - Make the AI building evaluation code use the new buildings.ruleset.
  90.  
  91. - Create a function that gives a statistically excact value for a units
  92.   chance of winning a battle.  [Now done.  What about expected number
  93.   of hit points remaing, or the variance?  Can we come up with clever
  94.   ways for the ai to use this information?]
  95.  
  96. - Make a function that can generate a warmap for airplanes.
  97.  
  98. - Convert the ai_manage_diplomat() function to use the warmap.
  99.  
  100. - Make the AI use the new automated ferryboat code. (note that the new
  101.   ferryboat code is not yet in CVS...)
  102.  
  103. - Make the AI respect FoW. (They don't get much bigger than this...)
  104.  
  105. - Make the goto on the server side (optionally?) respect FoW
  106.  
  107. - Teach the AI to Fortify units in non-city strategic positions. Also, it
  108.   needs to not idle all it's units every turn, breaking 2 turn fortify.
  109.  
  110. - Teach the AI to leave units alone in a turn to regain hit points. (it
  111.   seems to have no concept of this at all!)
  112.  
  113. - Stop the AI from trying to buy capitalization...
  114.  
  115. - Fix the AI valuation of supermarked. (It currently never builds it).
  116.   See farmland_food() and ai_eval_buildings() in advdomestic.c
  117.  
  118. - Teach the AI to coordinate the units in an attack (ok, this one is a bit
  119.   big...)
  120.  
  121. - Teach the AI to use ferryboats to transport explorers to unexplored land.
  122.   See ai_manage_explorer() and ai_manage_ferryboat().
  123.  
  124. Client goto related:
  125. - Make connect command find the connect route in the client and send it
  126.   to the server. Draw a line when chosing the connect route.
  127. - Find the goto route of an airplane in the client, and send it to
  128.   the server. Make the client draw the goto line. Note that you cannot
  129.   make a client_goto_map for airplanes with fuel. It may be fine to go
  130.   from p to q, and there may be a valid route from r to s via p, but
  131.   the route p->s is then not always usable without running out of fuel.
  132.   This makes the vectors in the client_goto_map unusable.
  133.   A solution would be a client_goto_map which held a lot more info per
  134.   tile, but that would not be nice I think. A better solution is
  135.   calculating the last part of the route dynamically as the mouse moves.
  136.   (maintain a list of the move costs to the refuel points to quickly
  137.   know if more than the last part needs recalculating)
  138. - Store the goto route in the client too. Keep it up to date as the unit
  139.   moves. Make middle-clicking the unit display the route by drawing the
  140.   line.
  141. - Perhaps make a check on all units on goto each turn to see if you could
  142.   find a better route than the current one. This would require the goto
  143.   route to be kept up to date in the client.
  144.   Note that this is not as simple as it seems, because a route A to B
  145.   with a waypoint C is often chosen not to be the fastest way from A to
  146.   B, but the route is still as it should be.
  147.  
  148. FURTHER INFORMATION:
  149. ====================
  150.  
  151. Information on other projects, and the Freeciv development
  152. "roadmap", are available at the Freeciv website:
  153.  
  154.         http://www.freeciv.org/
  155.